Add support to experimental features #7242

daxian-dbw · 2018-07-06T22:30:54Z

PR Summary

Goals:

Allow experimental features to be declared by PowerShell engine and modules.
Allow experimental features to be enabled via powershell.config.json
Allow Function, Cmdlet, parameters and parameter sets to be shown to the user or hiden from the user depending on whether the associated experimetnal feature is on or off.
Allow discover experimental features using cmdlet Get-ExperimentalFeature

No Goals:

Allow declaring and handling of experimental feature dependencies.
Show or hide PowerShell class depending on an experimental is on or off.

Engine Experimental Feature

Engine experimental features are required to register to the ExperimentalFeature type, by adding an ExperimentalFeature instance to ExperimentalFeature.EngineExperimentalFeatures in the type initailizer.

Module Experimental Feature

Module experimetnal features can declared by adding ExperimentalFeatures = @(..) to the PSData section of PrivateData in the module manifest. Example:

PrivateData = @{
    PSData = @{
        ExperimentalFeatures = @(
            @{ Name = 'ExpTest.FeatureOne'; Description = "Test feature number one." }
            @{ Name = 'ExpTest.FeatureTwo'; Description = "Test feature number two." }
        )
    }
}

Enable Experimental Features

Experimental features are enabled by declaring them in the powershell.config.json file. The enabled experimetnal features are fixed after powershell starts, and cannot be changed at run time.

{
  "Microsoft.PowerShell:ExecutionPolicy":"RemoteSigned",
  "ExperimentalFeatures": [
    "PSFileSystemProviderV2"
    "ExpTest.FeatureOne"
  ]
}

Exposed Public APIs

System.Management.Automation.ExperimentalAttribute. An attribute that can be applied to types or properties or fields. The attribute is used to support showing or hiding a command (Function, Cmdlet), or a command parameter.
A new constructor for ParameterAttribute: Parameter(string experimentalFeatureName, ExperimentAction). This constructor is used to support showing or hiding a parameter set.
System.Management.Automation.ExperimentAction. An enum with 3 members: "None", "Show", "Hide". This enum is used when creating an instance of ExperimentalAttribute, or ParameterAttribute with the new constructor. It indicate the action to take for a command or parameter when the associated feature is on or off.
System.Management.Automation.ExperimentalFeature. It represents an experimental feature, and it also exposes a static method bool HasEnabled(string featureName) for users to check if a given experimental feature is on.

New Type Accelerators

ExperimentAction for System.Management.Automation.ExperimentAction
Experimental for System.Management.Automation.ExperimentalAttribute
ExperimentalFeature for System.Management.Automation.ExperimentalFeature

New Cmdlet

Add Get-ExperimentalFeature [[-Name] <string[]>] [-ListAvailable] [<CommonParameters>] to retrieve information about experimental features from engine or modules. Name takes wildcards. When -ListAvailable is not specified, Get-ExperimentalFeature only returns the enabled experimental features (mimic Get-Module). When -ListAvailable is specified, Get-ExperimentalFeature returns all available experimental features from engine and modules in module paths.

PR Checklist

TravisEz13 · 2018-07-07T00:07:52Z

src/System.Management.Automation/engine/CommandCompletion/CompletionAnalysis.cs

@@ -1758,8 +1758,10 @@ private List<CompletionResult> GetResultForAttributeArgument(CompletionContext c
                List<CompletionResult> result = new List<CompletionResult>();
                foreach (PropertyInfo pro in propertyInfos)
                {
-                    //Ignore TypeId (all attributes inherit it)
-                    if (pro.Name != "TypeId" && (pro.Name.StartsWith(argName, StringComparison.OrdinalIgnoreCase)))


why did the != "TypeId go away?

The property TypeId is a read-only property. This change adds two more read-only properties to ParameterAttribute: ExperimentName and ExperimentAction. They shouldn't show up in the tab completion of Attribute properties because you cannot set values for them. So we should just ignore all getter properties.

TravisEz13 · 2018-07-07T00:15:24Z

src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs

+        }
+        private ExperimentAction _effectiveAction = default(ExperimentAction);
+    }
+}


missing newline

TravisEz13 · 2018-07-07T00:23:33Z

src/System.Management.Automation/engine/ExperimentalFeature/GetExperimentalFeatureCommand.cs

+            }
+        }
+    }
+}


TravisEz13 · 2018-07-07T00:26:51Z

src/System.Management.Automation/engine/InitialSessionState.cs

-                }
-                else
-                {
-                    s_PSSnapInTracer.WriteLine("Executing IModuleAssemblyInitializer.Import for {0}", assemblyPath);


seems like the snapin related changes would be better in a different PR

Actually, good catch here!
I reviewed my changes here again and this if...else... block shouldn't be removed. We should run ModuleInitializer when importing a binary module, even if the module was already loaded through an earlier import. I will revert this change.

TravisEz13 · 2018-07-07T00:39:05Z

src/System.Management.Automation/engine/Modules/AnalysisCache.cs

+                }
+
+                Array.Sort(featureNames);
+                string allNames = String.Join(Environment.NewLine, featureNames);


maybe it's better to join with a static value instead of NewLine? Is NewLine static or based on culture?

I think newline is platform based: \n vs \r\n

I looked into it, Environment.NewLine is compile-time static (the way corefx does it is they have a partial class with the shared part and then a .Unix.cs and a .Windows.cs, etc. and then they conditionally include it in compilation).

Yes, Environment.NewLine is static, \r\n on Windows and \n on Unix platforms. Here we are calculating a hash that is used locally for the analysis cache file name, so it's OK as long as it's consistent on a specific platform.

TravisEz13 · 2018-07-07T00:56:27Z

src/System.Management.Automation/resources/EventResource.resx

@@ -81,6 +81,16 @@
 InnerException: {3} 
 </value>
 </data>
+<data name="PS_PROVIDEReventE_O_ExperimentalFeatureInvalidName" xml:space="preserve">
+    <value>Experimental Feature Initialization: Ignore the experimental feature '{0}' from the config file. {1}</value>


seems on that the message doesn't say the name is invalid.

The {1} part will say why this name is invalid.

rjmholt · 2018-07-07T00:55:33Z

src/System.Management.Automation/engine/ExperimentalFeature/GetExperimentalFeatureCommand.cs

+        /// <summary>
+        /// Search module paths to find all available experimental features.
+        /// </summary>
+        [Parameter()]


Parentheses are used here but not above in a no-arg attribute -- should probably be consistent

daxian-dbw · 2018-07-10T01:01:15Z

@iSazonov I didn't make many style changes (maybe CommandProcessor.cs is the only outstanding file).
But there are many comments for style issues (var vs. explicit type, using named arguments for boolean values and etc.), so I push a separate commit to address most of the style related comments.

SteveL-MSFT · 2018-07-10T02:35:31Z

...stem.Management.Automation/FormatAndOutput/DefaultFormatters/PowerShellCore_format_ps1xml.cs

+            yield return new FormatViewDefinition("ExperimentalFeature",
+                TableControl.Create()
+                    .AddHeader(Alignment.Left, width: 35)
+                    .AddHeader(Alignment.Right, width: 10)


Why is the Enabled column width 10? Why not 7 (length of Enabled)?

Good point. Fixed.

SteveL-MSFT · 2018-07-10T02:36:19Z

...stem.Management.Automation/FormatAndOutput/DefaultFormatters/PowerShellCore_format_ps1xml.cs

+        {
+            yield return new FormatViewDefinition("ExperimentalFeature",
+                TableControl.Create()
+                    .AddHeader(Alignment.Left, width: 35)


Seems like Names should be terse (and unique), so 35 seems quite wide.

When it's a module feature (feature declared in module), the feature name would be longer than the module name. The width for module name is 35, and I also use 35 here for the feature name. If you still think we should use a smaller size, I can make that change.

Ok, for a module it makes sense. Let's leave it at 35 for now. Formatting changes aren't considered breaking so we can adjust later.

SteveL-MSFT · 2018-07-10T02:37:25Z

...stem.Management.Automation/FormatAndOutput/DefaultFormatters/PowerShellCore_format_ps1xml.cs

+                TableControl.Create()
+                    .AddHeader(Alignment.Left, width: 35)
+                    .AddHeader(Alignment.Right, width: 10)
+                    .AddHeader(Alignment.Left, width: 35)


35 here also seems wide for the Source?

For a module feature, the source is the path to the module manifest file. That's why I also make the width 35. Let me know if you think we should use a smaller size.

Ok for now.

SteveL-MSFT · 2018-07-10T02:41:05Z

src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs

+
+using System.Collections.Generic;
+using System.Collections.ObjectModel;
+using System.Collections.Immutable;


I comes before O. You almost have these in alphabetical order

I don't see the fix.

SteveL-MSFT · 2018-07-10T03:06:02Z

src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs

+            int firstDotIndex = featureName.IndexOf('.');
+            int lastDotIndex = featureName.LastIndexOf('.');
+
+            bool legit = firstDotIndex > 0 && lastDotIndex < featureName.Length - 1;


Is this more performant than just

bool legit = !featureName.StartsWith(".") && !featureName.EndsWith(".")

? Which seems a bit more descriptive.

SteveL-MSFT · 2018-07-10T03:11:33Z

src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs

-            object privateData = null;
-            if (data.Contains("PrivateData"))
+            // Set the private data member for the module if the manifest contains this member
+            object privateData = data["PrivateData"];


PrivateDate and PSData should be members of SpecialVariables

But they are not variables ... They are module manifest keys.
We could have a static type called ModuleManifestKeys, where we can define all manifest key const strings just like SpecialVariables. But we can do it in a separate PR.

SteveL-MSFT · 2018-07-10T03:23:52Z

test/powershell/engine/ExperimentalFeature/ExperimentalFeature.Basic.Tests.ps1

+            $AssemblyPath = Join-Path $TestModule "ExpTest.dll"
+            if (-not (Test-Path $AssemblyPath)) {
+                ## When using $SourcePath directly, 'Add-Type' fails in AppVeyor CI runs with an 'access denied' error.
+                ## It turns out Pester doesn't handle an exception like this from 'BeforeAll'. It causes the Pester to


Did we open an issue in Pester repo or does one already exist?

Didn't open an issue yet. Will do.

Can you add link to bug in comment? Don't want future tests following this pattern if it gets fixed in Pester.

Will do after I open the issue.

SteveL-MSFT · 2018-07-10T03:28:18Z

test/powershell/engine/ExperimentalFeature/ExperimentalFeature.Basic.Tests.ps1

+        param($Name, $CommandType)
+        $command = Get-Command $Name
+        $command.CommandType | Should -Be $CommandType
+        ## 11 common parameters + '-Name'


For future maintenance of this code, it would be better to have something like:

BeforeAll { $commonParameters = @('a','b','c',...) } ... $command.Parameters.Count | Should -Be ($commonParameters + "-Name").Length

Apply in all cases below. I think it removes the need for the comments.

I should have used [System.Management.Automation.Internal.CommonParameters].GetProperties().Length to get the count of common parameters. I will make the change.

SteveL-MSFT · 2018-07-10T03:37:47Z

test/powershell/engine/ExperimentalFeature/assets/ExpTest/ExpTest.psm1

+    }
+}
+
+#endregion


You're missing a test cases for:

[Experimental()]

ExperimentAction.None

ExperimentName starting and ending with period

Tests added.

iSazonov · 2018-07-10T07:24:56Z

src/System.Management.Automation/engine/Attributes.cs

+        #region Experimental Feature Related Properties
+
+        /// <summary>
+        /// Name of the experimental feature this attribute is associated with.


Should be: "Gets name of the experimental feature this attribute is associated with."

iSazonov · 2018-07-10T07:25:23Z

src/System.Management.Automation/engine/Attributes.cs

+        public string ExperimentName { get; }
+
+        /// <summary>
+        /// Action for engine to take when the experimental feature is enabled.


Should be "Gets action for engine to take when the experimental feature is enabled."

iSazonov · 2018-07-10T07:26:09Z

src/System.Management.Automation/engine/Attributes.cs

+        internal bool ToShow => EffectiveAction == ExperimentAction.Show;
+
+        /// <summary>
+        /// Effective action to take at run time.


Should be "Gets effective action to take at run time.".

iSazonov · 2018-07-10T07:29:39Z

src/System.Management.Automation/engine/CommandCompletion/CompletionAnalysis.cs

-                    //Ignore TypeId (all attributes inherit it)
-                    if (pro.Name != "TypeId" && (pro.Name.StartsWith(argName, StringComparison.OrdinalIgnoreCase)))
+                    // Ignore getter-only properties, including 'TypeId' (all attributes inherit it).
+                    if (!property.CanWrite) { continue; }


Seems our convention is

if (!property.CanWrite) continue;

or

if (!property.CanWrite) { continue; }

I'd prefer second.

We use if () { // simple statement } all over the code base. But I don't think we should allow the first pattern in your comment. The if body should always be in { }.

Certainly agree that we should always use braces.

In a world where we no longer use teletypes (i.e. where screens are big and newlines are cheap), I tend to feel that we should always just hang the line so that as my eyes scan down a document at an approximate indentation level and always know what's going on. But, that's just a style preference, and inline-braces are still pretty good to me.

iSazonov · 2018-07-10T07:35:05Z

src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs

+
+using System.Collections.Generic;
+using System.Collections.ObjectModel;
+using System.Collections.Immutable;


I don't see the fix.

iSazonov · 2018-07-10T11:03:44Z

src/System.Management.Automation/engine/parser/Compiler.cs

            }

+            // If all 'ParameterAttribute' declared for the parameter are hidden due to
+            // an experimental feature, then the parameter should be ignored.
+            if (hasParameterAttribute && !hasEnabledParamAttribute) { return null; }


Please use multiline formatting.

iSazonov · 2018-07-10T11:04:28Z

src/System.Management.Automation/engine/parser/Compiler.cs

            attributes.Reverse();
            if (!hasParameterAttribute)
            {
                attributes.Insert(0, new ParameterAttribute());
            }

            var result = new RuntimeDefinedParameter(parameterAst.Name.VariablePath.UserPath, parameterAst.StaticType,
-                                                     new Collection<Attribute>(attributes.ToArray()));
+                                                     new Collection<Attribute>(attributes));


Formatting - please place one parameter per line.

iSazonov · 2018-07-10T11:04:54Z

src/System.Management.Automation/engine/parser/ast.cs

+                {
+                    var attributeAst = ParamBlock.Attributes[index];
+                    var expAttr = GetExpAttributeHelper(attributeAst);
+                    if (expAttr != null) { yield return expAttr; }


Please use multiline formatting.

iSazonov · 2018-07-10T11:08:21Z

src/System.Management.Automation/engine/parser/ast.cs

+                    {
+                        return Compiler.GetAttribute(potentialExpAttr) as ExperimentalAttribute;
+                    }
+                    catch (Exception) { /* catch all and assume it's not a declaration of ExperimentalAttribute */ }


I guess we get style issues in CodeFactor for the formatting.

I will update this one as it's not exactly an empty catch body.

iSazonov · 2018-07-10T11:11:03Z

src/System.Management.Automation/resources/RunspaceInit.resx

@@ -117,6 +117,9 @@
  <resheader name="writer">
    <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>
+  <data name="EnabledExperimentalFeatures" xml:space="preserve">
+    <value>Variable to hold the enabled experimental feature names</value>


Should we add final dot?

I followed the existing examples. I don't have a strong opinion. It looks OK to me without the dot:

PS:8> $v.Description Parent folder of the host application of the current runspace

SteveL-MSFT · 2018-07-10T16:28:27Z

test/powershell/engine/ExperimentalFeature/ExperimentalFeature.Basic.Tests.ps1

+    }
+
+    It "Argument validation for constructors of 'ExperimentalAttribute' and 'ParameterAttribute'" {
+        { [Experimental]::new("", "None") } | Should -Throw -ErrorId "PSArgumentNullException"


Would be better to have these as TestCases so that the first failure doesn't prevent the rest from running

Will update the test.

daxian-dbw · 2018-07-10T20:45:17Z

@iSazonov About the style rules, @TravisEz13, @adityapatwardhan and I went through all issues reported from CodeFactor a few weeks back, and we got a list of rules that we think should be turned off. Here is the list:
1305: SA1305FieldNamesMustNotUseHungarianNotation
1502: SA1502ElementMustNotBeOnSingleLine
1310: SA1310FieldNamesMustNotContainUnderscore,
1204: SA1204StaticElementsMustAppearBeforeInstanceElements
1009: SA1009ClosingParenthesisMustBeSpacedCorrectly
1501:SA1501StatementMustNotBeOnSingleLine
1513:SA1513ClosingBraceMustBeFollowedByBlankLine
1306:SA1306FieldNamesMustBeginWithLowerCaseLetter
1308:SA1308VariableNamesMustNotBePrefixed
1013:SA1013ClosingBracesMustBeSpacedCorrectly
1500:SA1500BracesForMultiLineStatementsMustNotShareLine
1010:SA1010OpeningSquareBracketsMustBeSpacedCorrectly
1026:SA1026CodeMustNotContainSpaceAfterNewKeywordInImplicitlyTypedArrayAllocation
1008:SA1008OpeningParenthesisMustBeSpacedCorrectly
1311:SA1311StaticReadonlyFieldsMustBeginWithUpperCaseLetter
1025:SA1025CodeMustNotContainMultipleWhitespaceInARow
1012:SA1012OpeningBracesMustBeSpacedCorrectly
1215:SA1215InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements
1214:SA1214ReadonlyElementsMustAppearBeforeNonReadonlyElements
1210:SA1210UsingDirectivesMustBeOrderedAlphabeticallyByNamespace
1609:SA1609PropertyDocumentationMustHaveValue

The rules about "one parameter per line" for method definition or invocation is not in this list, but in my opinion, we probably should disable that rule because 1) it doesn't bring much benefit -- as long as the parameters are well aligned, there is no readability issue; 2) there are too many instances in our existing code base that are violating that rule, and fixing all doesn't worth the time.

The following document rules make sense for public members, but they are applied to non-public members too, which causes a lot of noise data.

1611:SA1611ElementParametersMustBeDocumented
1615:SA1615ElementReturnValueMustBeDocumented
1606:SA1606ElementDocumentationMustHaveSummaryText

iSazonov · 2018-07-11T05:00:09Z

@daxian-dbw I moved your style comment in Issue #4708.

daxian-dbw · 2018-07-11T05:13:18Z

@iSazonov Thanks for moving it to the right place. I will spend more time refining the rules for CodeFactor after finishing the first check-in of the experimental feature work.

rjmholt · 2018-07-11T23:17:12Z

src/System.Management.Automation/engine/CommandCompletion/CompletionAnalysis.cs

-                    //Ignore TypeId (all attributes inherit it)
-                    if (pro.Name != "TypeId" && (pro.Name.StartsWith(argName, StringComparison.OrdinalIgnoreCase)))
+                    // Ignore getter-only properties, including 'TypeId' (all attributes inherit it).
+                    if (!property.CanWrite) { continue; }


Certainly agree that we should always use braces.

In a world where we no longer use teletypes (i.e. where screens are big and newlines are cheap), I tend to feel that we should always just hang the line so that as my eyes scan down a document at an approximate indentation level and always know what's going on. But, that's just a style preference, and inline-braces are still pretty good to me.

rjmholt · 2018-07-11T23:20:52Z

src/System.Management.Automation/engine/Modules/AnalysisCache.cs

-            s_cacheStoreLocation =
-                Environment.GetEnvironmentVariable("PSModuleAnalysisCachePath") ??
+            // If user defines a custom cache path, then use that.
+            string userDefinedCachePath = Environment.GetEnvironmentVariable("PSModuleAnalysisCachePath");


I would say it does constitute a public API, so we ought to document it, although there's not really much need

rjmholt · 2018-07-11T23:31:14Z

src/System.Management.Automation/engine/ExperimentalFeature/GetExperimentalFeatureCommand.cs

+        /// Engine features come before module features.
+        /// Within engine features and more features, features are ordered by name.
+        /// </remarks>
+        private static string GetSortingString(ExperimentalFeature feature)


@daxian-dbw This is the only thing remaining I can think of. May not be significant, but returning (int, string) here might save some allocations

rjmholt · 2018-07-11T23:31:29Z

src/System.Management.Automation/engine/ExperimentalFeature/GetExperimentalFeatureCommand.cs

+        /// </remarks>
+        private static string GetSortingString(ExperimentalFeature feature)
+        {
+            if (ExperimentalFeature.EngineSource.Equals(feature.Source))


Does this need to be case insensitive?

I was assuming people will use the const string field ExperimentalFeature.EngineSource for registering an engine exp feature, but it's more reliable to make this comparison case insensitive.

…ing key

daxian-dbw · 2018-07-12T21:46:30Z

@TravisEz13 is on vacation. I assigned this PR to @adityapatwardhan

adityapatwardhan

Minor nitpick. Looks good otherwise.

adityapatwardhan · 2018-07-09T17:42:46Z

src/PowerShell.Core.Instrumentation/PowerShell.Core.Instrumentation.man

+            />
+        <string
+            id="PS_PROVIDER.event.E_O_ExperimentalFeatureReadConfigError.message"
+            value="Experimental Feature Initialization: Failed to read the config file.%n Exception: %1 %n Message: %2 %n StackTrace: %3 %n"


Is there a space needed between file. and %n

%n is a new line, so no space is needed here. For Exception: %1 %n Message: %2 %n StackTrace: %3 %n, the space character before %n is not necessary, but it's been that way in other places of this manifest file, so I followed the existing pattern.

iSazonov · 2018-07-13T03:55:17Z

@daxian-dbw Congratulations on this great work! 👍

The PR resolves some style issues in engine code. (Moved from PR #7242. )

daxian-dbw added 9 commits July 6, 2018 13:28

First batch: Basic experimental feature flag and attributes enforced

eed9842

Update code that creates attributes to support the new attribute changes

930350e

Support experimental feature in modules

8a5ddbb

Add 'Get-ExperimentalFeature' cmdlet

7770aa5

Add logging, formatting, and '$EnabledExperimentalFeatures'

dc2d741

Generate logging resources for Unix platforms

d8d3344

Alter the analysis cache file name properly

3c3ddeb

[Feature] Add tests for experimental feature work

d2e9151

[Feature] Fix two tests

bc8abf8

daxian-dbw added the Documentation Needed in this repo Documentation is needed in this repo label Jul 6, 2018

daxian-dbw requested review from BrucePay, rjmholt, TravisEz13, SteveL-MSFT, dantraMSFT, adityapatwardhan, PaulHigin and iSazonov July 6, 2018 22:30

daxian-dbw requested review from anmenaga and mirichmo as code owners July 6, 2018 22:30

daxian-dbw requested review from JamesWTruher and removed request for mirichmo July 7, 2018 00:03

TravisEz13 reviewed Jul 7, 2018

View reviewed changes

rjmholt requested a review from TylerLeonhardt July 7, 2018 00:52

TravisEz13 reviewed Jul 7, 2018

View reviewed changes

rjmholt reviewed Jul 7, 2018

View reviewed changes

daxian-dbw changed the title ~~[WIP] Add support to experimental features~~ Add support to experimental features Jul 10, 2018

SteveL-MSFT requested changes Jul 10, 2018

View reviewed changes

[Feature] Address Feedback: Use better error message and add more tests

2c9519b

iSazonov reviewed Jul 10, 2018

View reviewed changes

SteveL-MSFT requested changes Jul 10, 2018

View reviewed changes

[Feature] Address Feedback: Fix style and xml doc issues. Update tests

0ac878f

SteveL-MSFT approved these changes Jul 10, 2018

View reviewed changes

iSazonov approved these changes Jul 11, 2018

View reviewed changes

[Feature] Address Feedback: Do not override user defined cache path

add14e4

iSazonov approved these changes Jul 11, 2018

View reviewed changes

rjmholt approved these changes Jul 11, 2018

View reviewed changes

[Feature] Address Feedback: Use value tuple (int, string) as the sort…

d12230f

…ing key

iSazonov assigned TravisEz13 Jul 12, 2018

daxian-dbw assigned adityapatwardhan and unassigned TravisEz13 Jul 12, 2018

adityapatwardhan approved these changes Jul 12, 2018

View reviewed changes

adityapatwardhan merged commit 75ba74c into PowerShell:master Jul 12, 2018

daxian-dbw deleted the exp branch July 12, 2018 22:53

iSazonov mentioned this pull request Aug 9, 2018

Add a parallel % (foreach-object) #3008

Closed

TravisEz13 pushed a commit that referenced this pull request Aug 14, 2018

Fix some style issues in engine code (#7246)

4ee1973

The PR resolves some style issues in engine code. (Moved from PR #7242. )

iSazonov mentioned this pull request Aug 29, 2018

Add ability to turn experimental features on/off #2670

Closed

joeyaiello mentioned this pull request Oct 15, 2018

Docs needed for 'Add support to experimental features' MicrosoftDocs/PowerShell-Docs#3030

Closed

joeyaiello removed Documentation Needed in this repo Documentation is needed in this repo labels Oct 15, 2018

Add support to experimental features #7242

Add support to experimental features #7242

Conversation

daxian-dbw commented Jul 6, 2018 • edited by rjmholt

PR Summary

Engine Experimental Feature

Module Experimental Feature

Enable Experimental Features

Exposed Public APIs

New Type Accelerators

New Cmdlet

PR Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daxian-dbw Jul 9, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daxian-dbw commented Jul 10, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daxian-dbw Jul 10, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daxian-dbw Jul 10, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daxian-dbw commented Jul 10, 2018

iSazonov commented Jul 11, 2018

daxian-dbw commented Jul 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daxian-dbw commented Jul 12, 2018

adityapatwardhan left a comment

daxian-dbw commented Jul 6, 2018 •

edited by rjmholt

daxian-dbw Jul 9, 2018 •

edited

daxian-dbw Jul 10, 2018 •

edited

daxian-dbw Jul 10, 2018 •

edited

daxian-dbw Jul 12, 2018 •

edited